In computer networks and other distributed computing systems, a copy of data that originally resides on one computer is often requested by processes or users at other computers. The requested data may be part of a file, selected database records, executable code, or other data or components. In order to reduce network traffic, improve response time, and otherwise increase efficiency, various caching systems have been devised. In general, caching promotes efficiency by placing data in memory at a location which is more readily accessed by the requesting process than the data's original location. Caching and networks are discussed in numerous references, including U.S. Pat. No. 5,594,863 issued to Stiles for a Method and Apparatus for Network File Recovery, incorporated herein by reference.
A variety of "directory service" providers are now available to help administer both the location of network resources and the rights of network users to use those resources. Many, but not all, directory service tools conform at least in part with the X.500 directory services standard. Directory services are sometimes referred to as "naming services." One well-known directory services system includes NetWare Directory Services software commercially available from Novell, Inc. of Provo, Utah (NETWARE DIRECTORY SERVICES is a trademark of Novell, Inc.). As used herein, "Novell Directory Services" ("NDS") includes NetWare Directory Services and any other directory service commercially available from Novell, Inc. Directory services and NDS are discussed in numerous references, including U.S. patent application Ser. No. 08/499,711 in the name of Sonderegger et al., incorporated herein by reference.
Known network caching methods are less useful with directory service data than with other forms of network data because directory service data contains more references. References may be in the form of server addresses, database object identifiers, or other structures containing indexes, pointers, addresses, or other references further identifying the location of desired resources or data.
FIG. 1 illustrates the importance of references in a known directory services system. The system includes clients and servers connected in a network, as well as a directory service database or repository which resides in one or more replicas on one or more of the servers. On some platforms, a "client" computer running client software is in fact the same computer as a "server" computer; that is, the same computer acts as both server and client. Different systems may utilize references in ways other than those illustrated, but the use of references is not unusual whenever objects identified by users through logical names must be matched with one or more physical copies of the objects which are stored at physical locations hidden from (transparent to) the application and the user.
One common sequence of directory service events begins when an application request 100 is sent to a client 102. The request 100 may be any of a wide variety of requests that cause access to the database, including without limitation a request to read or write the attributes of an object in a database, in a registry, or in another repository. The request 100 may be generated, directly or indirectly, by Novell GroupWise software, by Novell Client32 software, or by other networked or groupware programs running on multiple platforms such as DOS, Windows 3.1, Windows 95, Windows NT, OS/2, NetWare (trademarks of their respective owners), and other platforms. A networked database system is only one of many possible examples. If the client and server are the same computer acting in different roles, then it is possible that the request 100 and other communications are sent by message routing through several software layers on the computer, making it indistinguishable at some point from communications which traveled from a remote client over a network connection.
The request 100 identifies the object in question by a distinguished name 104, or by part of the distinguished name 104 plus contextual information that allows the client 102 to construct the full distinguished name 104. The distinguished name 104 may be an NDS distinguished name or another database-wide or system-wide component identifier. The client 102 sends the distinguished name 104 to a server 106 (called "server A" for purposes of discussion) in order to find out where a copy of the object identified by the distinguished name 104 physically resides in the network. In many cases, the details of the request 100 greatly increase the size of the packet(s) being sent, so the client 102 tries to find a server that can use the details to service the request 100 before using the bandwidth needed to send the details.
Server A either has a copy of the object that can be used to respond to the request 100, or it does not. If server A has a copy, it sends an internal identifier 108 back to the client 102. The internal identifier 108, which corresponds to an instance of the object identified by the distinguished name 104, may include an entry identifier of the kind used in NDS or another replica-wide component identifier. The internal identifier 108 may include an inventive "tuned name" of the kind discussed in U.S. application Ser. No. 08/764,236 filed Dec. 14, 1996 and incorporated here by reference, or the identifier 108 may include another kind of internal object identifier.
Even if server A does not have a copy of the object, it may still have useful information about the location of the desired copy. In the illustrated sequence, server A sends the client 102 a list 110 of other servers that might have a copy of the object. For purposes of discussion, the list 110 shown in FIG. 1 is assumed to contain addresses identifying three other servers 106, denoted "B," "C," and "D," respectively. As shown, the client 102 then sends the distinguished name 104 to the identified servers in turn (this could also be done in parallel), until one of the servers indicates the availability of a copy of the desired object by returning the object's internal identifier 108. If a requested server 106 does not have a copy of the object, it may return another server list 110. Alternatively, the server 106 may return a negative acknowledgment 112 if it has no copy and if the client 102 indicates that no further server lists 110 are needed.
As illustrated in FIG. 1, it is not unusual for the client 102 to contact several servers 106 before finding one that will give the client 102 access to a copy of the desired object. Once such a server 114 is found (the server 114 being either server A or server D in the illustrated sequences), the client 102 sends the internal identifier and associated details 116 to the server 114. The server 114 processes the request and returns the results 118 to the client 102.
Unfortunately, most or all of this process is repeated if a second request 100 arrives, the main difference being that fewer--or more--servers 106 may need to be queried to service this second request 100. Most of the process is repeated, even if the distinguished name 104 in the second request 100 also appeared in the first request 100. These repeated server contacts take time, and increase the load on network connections.
Moreover, the problem is not limited to the sequences illustrated, or even to directory service databases. Other distributed databases are subject to similar inefficiencies when references are used to translate logical, high-level identifiers into lower-level physical locations of distributed and/or replicated data objects and records.
It would therefore be an advancement in the art to provide a method and system for improving the speed and efficiency with which references are used in a distributed system.
It would be an additional advancement to provide such a method and system which reduced network traffic and server queries in a directory services system.
Such a method and system are disclosed and claimed herein.